\section{Suggested Solution}
As mentioned in the section above, the solution was implemented in two manners. As suggested in the exercise description, the solution was first written without interrupts, and secondly with an interrupt routine. This section will first describe how the STK1000 was set up for the exercise. It further moves on to the general approach of solving the problem, before detailing the solution with interrupts enabled. Section \ref{subsec:interrupts} will also highlight the difference between using interrupts and not.

\subsection{Hardware Setup}
\label{subsec:hardware}
This section describes the general approach towards solving the problem described in Section \ref{sec:introduction}. Before implementation could be started, the STK1000 board needed to be configured to an appropriate setup. The \emph{General Purpose Input Output(GPIO)} pins 0-7 to SWITCH pins 0-7 was first connected with a flat cable. A second cable was used to connect the GPIO pins 16-23 to LED pins 0-7.
\\\\
Effectively these connections let us control LED lights through \emph{Programmed Input Output (PIO)} port B pins 0 to 7, and the buttons through PIO port C pins 0 to 7 in our program. The PIO B and PIO C base adresses in memory were provided to us in the exercise's code skeleton along with offsets to relevant registers.
\\\\
To finalize the hardware setup, jumpers were set as described in the exercise description. The JTAGICE mk II was then conncted to the STK1000 board concluding the hardware setup phase.

\subsection{General Approach}
\label{subsec:genappr}
The implementation part of our solution is divided into four main parts:
\begin{description}
	\item[Initialization:]is the starting point of the application and initializes the microcontroller into its preferred state.
	\item[Main loop:]is the main program loop.
	\item[Reading input:]registers the current state of the buttons.
	\item[Moving LED:]moves the LED light to the right and left and enforces the light position to stay within the boundaries of the array (between LED position 0 and 7).
\end{description}

A problem that rises regardless of using interrupts or not, is that the light should only move when a button is pressed down. A naive approach here is to read the button states and move the light when the corresponding button is in a "down" position. This solution produces an incorrect result because multiple, consecutive readings from the same button will occur, resulting in the light moving to a boundary position.

Our solution to this problem is to store the last state of buttons. When reading the current state of the buttons we compare it to the last state. If the comparison shows that a button was pressed down in its last state and still remains pressed down, we will not act on the currently pressed button nor update the light's position.

Another challenge in the exercise is to prevent the light from moving outside LED 0 and LED 7. LEDs are turned on by writing a mask to the \emph{Set Output Data Register (SODR)} and turned off by writing to the \emph{Clear Output Data Register (CODR)} of PIO port C with our hardware setup. The eight least significant bits of the mask controls the corresponding eight LEDs. To keep track of where the light currently resides, we used register R3 to store this value. In practice this means that the binary number of e.g. 0000 0001 indicates the light to be at position zero. Using this scheme makes it very easy to increment/decrement the light position by using a binary shift to either the left or right using the assembly commands \emph{lsr} and \emph{lsl} \cite[p. 108]{avr32_arch}. However it is crucial to not let the bit shift too far to the left or right, to enforce the requirements of the exercise. To cope with this we split up the light movement routines into separate routines for moving left and right. These routines checks if the light's position is already at the boundary positions and will not move the light if this is the case. Moving the light itself means turning off the LED at the current position, updating the light position in R3 and turning on the LED at the new position.

\subsection{Application of Interrupts}
\label{subsec:interrupts}
As already mentioned in Section \ref{sec:introduction}, the first program, which also worked correctly, read the input, i.e. the buttons, constantly in a infinite loop so that the push of a button could be tracked. In bigger programs, especially with several hardware inputs, this solution might be impractical and leads to problems. A better way is through the application of interrupts. When using interrupts two major benefits rise. First and foremost the program does not have to deal with the code for reading input constantly, thus freeing up CPU time. Secondly the program scales better because in a program where the execution time is long and the program therefore reads its intput seldom, there is no guarantee that the users input coincides with the input reading routines. Using interrupts halts the current execution and breaks to the interrupt routine, eliminating this problem. As a third benefit interrupt enforces modifiability because there is no direct dependency between the main loop and the (in this case) input handling.

It is necessary to initialize the microcontroller in a way that it accepts interrupts from the hardware devices of interest, and only from these. Thus for the button array used with the hardware set-up mentioned in Section \ref{subsec:hardware} the following lines were added:

\begin{lstlisting}
mov r2, 0x0
mtsr 4, r2	/* load EVBA */
mov r2, input_interrupt
/* INTC-base-address is in r8 */
st.w r8[AVR32_INTC_IPR14], r2 
...
csrf SR_GM	/* constant SR_GM = 16 */
\end{lstlisting}

Since the interrupt-routine should be part of the \lstinline&.text&-segment the EVBA can be set to 0. In addition to that the autovector for the interrupt-routine (here \lstinline&input_interrupt&) and the correct interrupt line (here 0) must be written into the interrupt priority register (IPR) that belong to the PIO port B (buttons). That register has number 14. The last step to make the processor accept interrupts is to clear the GM-bit of the status register (for detailed description see \cite[page 11ff.]{avr32_arch})

After that an empty infinite loop, in which the processor waits for interrupts, is entered. It looks like this:

\begin{lstlisting}
loop:   /* main loop */
        rjmp loop
\end{lstlisting}

In this state a push of button 0 or 2 let the processor enter the interrupt-routine \lstinline&input_interrupt&. In the beginning all registers that are used inside the routine are pushed onto the stack \cite[page 32]{kompendium} to be able to restore their original values before returning from the exception (interrupt routine). Although this procedure is not absolutely necessary in the program that is presented here it is important to do it, because especially in bigger programs one often do not know which registers are used by the interrupted ``main program'', respectively all registers are used.

Directly after these stack operations a small loop with the label \lstinline&intr_sleep_start& is entered. Its function is to avoid the bouncing of the buttons and hence the occurrence of several interrupts. Therefore it decrements a certain number \footnote{here 0xFFF (found by testing)} until it is zero. While the loop is running no new interrupts are accepted, because the \emph{Interrupt Status Register (ISR)} is not read until the loop is finished. The time the loop is running the contact of the button stabilizes. However the time must also not be too long, because otherwise the button may already be released and the value that is read from \emph{Pin-Data Status Register (PDSR)} causes the program to work not correct. A long debouncing routine also wastes CPU time because no actual work is done.

After the debouncing-routine the actual handling of the interrupt starts. Therefore the button state, i.e. a 1 for a pushed button at the according bit position, from the last interrupt is read from a variable \lstinline&current_button_state& which is located in the \lstinline&.data&-segment. In the next steps the ISR and the PDSR are read. The value that comes from the PDSR will then be negated and masked with 0b00\ldots0101 in order to have a register in which all bits are zero except of a bit that belongs to a pushed button. With the last button state it is decided if the button is pushed or released. If the button is pushed, i.e. last value is zero, the program will go on with the decision whether to move the light right or left, else it will return from the exception. The moves to the right and to the left are implemented as subroutines and work as described in Section \ref{subsec:genappr}. After returning from one of the subroutines the original register values need to be popped from the stack.